home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1796.txt < prev    next >
Text File  |  1997-04-01  |  7KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         C. Huitema
  8. Request for Comments: 1796                                         INRIA
  9. Category: Informational                                        J. Postel
  10.                                                                      ISI
  11.                                                               S. Crocker
  12.                                                                CyberCash
  13.                                                               April 1995
  14.  
  15.  
  16.                        Not All RFCs are Standards
  17.  
  18. Status of this Memo
  19.  
  20.    This memo provides information for the Internet community.  This memo
  21.    does not specify an Internet standard of any kind.  Distribution of
  22.    this memo is unlimited.
  23.  
  24. Abstract
  25.  
  26.    This document discusses the relationship of the Request for Comments
  27.    (RFCs) notes to Internet Standards.
  28.  
  29. Not All RFCs Are Standards
  30.  
  31.    The "Request for Comments" (RFC) document series is the official
  32.    publication channel for Internet standards documents and other
  33.    publications of the IESG, IAB, and Internet community.  From time to
  34.    time, and about every six months in the last few years, someone
  35.    questions the rationality of publishing both Internet standards and
  36.    informational documents as RFCs.  The argument is generally that this
  37.    introduces some confusion between "real standards" and "mere
  38.    publications".
  39.  
  40.    It is a regrettably well spread misconception that publication as an
  41.    RFC provides some level of recognition.  It does not, or at least not
  42.    any more than the publication in a regular journal.  In fact, each
  43.    RFC has a status, relative to its relation with the Internet
  44.    standardization process: Informational, Experimental, or Standards
  45.    Track (Proposed Standard, Draft Standard, Internet Standard), or
  46.    Historic.  This status is reproduced on the first page of the RFC
  47.    itself, and is also documented in the periodic "Internet Official
  48.    Protocols Standards" RFC (STD 1).  But this status is sometimes
  49.    omitted from quotes and references, which may feed the confusion.
  50.  
  51.    There are two important sources of information on the status of the
  52.    Internet standards:  they are summarized periodically in an RFC
  53.    entitled "Internet Official Protocol Standards" and they are
  54.    documented in the "STD" subseries.  When a specification has been
  55.  
  56.  
  57.  
  58. Huitema, Postel & Crocker                                       [Page 1]
  59.  
  60. RFC 1796               Not All RFCs are Standards             April 1995
  61.  
  62.  
  63.    adopted as an Internet Standard, it is given the additional label
  64.    "STD xxxx", but it keeps its RFC number and its place in the RFC
  65.    series.
  66.  
  67.    It is important to note that the relationship of STD numbers to RFC
  68.    numbers is not one to one.  STD numbers identify protocols, RFC
  69.    numbers identify documents.  Sometimes more than one document is used
  70.    to specify a Standard protocol.
  71.  
  72.    In order to further increase the publicity of the standardization
  73.    status, the IAB proposes the following actions:
  74.  
  75.       Use the STD number, rather than just the RFC numbers, in the cross
  76.       references between standard tracks documents,
  77.  
  78.       Utilize the "web" hypertext technology to publicize the state of
  79.       the standardization process.
  80.  
  81.    More precisely, we propose to add to the current RFC repository an
  82.    "html" version of the "STD-1" document, i.e., the list of Internet
  83.    standards.  We are considering the extension of this document to also
  84.    describes actions in progress, i.e., standards track work at the
  85.    "proposed" or "draft" stage.
  86.  
  87. A Single Archive
  88.  
  89.    The IAB believes that the community benefitted significantly from
  90.    having a single archival document series.  Documents are easy to find
  91.    and to retrieve, and file servers are easy to organize.  This has
  92.    been very important over the long term.  Experience of the past shows
  93.    that subseries, or series of limited scope, tend to vanish from the
  94.    network.  And, there is no evidence that alternate document schemes
  95.    would result in less confusion.
  96.  
  97.    Moreover, we believe that the presence of additional documents does
  98.    not actually hurt the standardization process.  The solution which we
  99.    propose is to better publicize the "standard" status of certain
  100.    documents, which is made relatively easy by the advent of networked
  101.    hypertext technologies.
  102.  
  103. Rather Document Than Ignore
  104.  
  105.    The RFC series includes some documents which are informational by
  106.    nature and other documents which describe experiences.  A problem of
  107.    perception occurs when such a document "looks like" an official
  108.    protocol specification.  Misguided vendors may claim conformance to
  109.    it, and misguided clients may actually believe that they are buying
  110.    an Internet standard.
  111.  
  112.  
  113.  
  114. Huitema, Postel & Crocker                                       [Page 2]
  115.  
  116. RFC 1796               Not All RFCs are Standards             April 1995
  117.  
  118.  
  119.    The IAB believes that the proper help to misguided vendors and
  120.    clients is to provide them guidance.  There is actually very little
  121.    evidence of vendors purposely attempting to present informational or
  122.    experimental RFCs as "Internet standards".  If such attempts
  123.    occurred, proper response would indeed be required.
  124.  
  125.    The IAB believes that the community is best served by openly
  126.    developed specifications.  The Internet standardization process
  127.    provides guarantees of openness and thorough review, and the normal
  128.    way to develop the specification of an Internet protocol is indeed
  129.    through the IETF.
  130.  
  131.    The community is also well served by having access to specifications
  132.    of which have been developed outside the IETF standards process,
  133.    either because the protocols are experimental in nature, were
  134.    developed privately, or failed to achieve the acquire the degree of
  135.    consensus required for elevation to the standards track.
  136.  
  137.    The IAB believes that publication is better than ignorance.  If a
  138.    particular specification ends up being used in products that are
  139.    deployed over the Internet, we are better off if the specification is
  140.    easy to retrieve as an RFC than if it is hidden in some private
  141.    repository.
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Huitema, Postel & Crocker                                       [Page 3]
  171.  
  172. RFC 1796               Not All RFCs are Standards             April 1995
  173.  
  174.  
  175. Security Considerations
  176.  
  177.    Security issues are not discussed in this memo.
  178.  
  179. Authors' Addresses
  180.  
  181.    Christian Huitema
  182.    INRIA, Sophia-Antipolis
  183.    2004 Route des Lucioles
  184.    BP 109
  185.    F-06561 Valbonne Cedex
  186.    France
  187.  
  188.    Phone: +33 93 65 77 15
  189.    EMail: Christian.Huitema@MIRSA.INRIA.FR
  190.  
  191.  
  192.    Jon Postel
  193.    USC/Information Sciences Institute
  194.    4676 Admiralty Way
  195.    Marina del Rey, CA 90292
  196.  
  197.    Phone: 1-310-822-1511
  198.    EMail: Postel@ISI.EDU
  199.  
  200.  
  201.    Steve Crocker
  202.    CyberCash, Inc.
  203.    2086 Hunters Crest Way
  204.    Vienna, VA 22181
  205.  
  206.    Phone: 1- 703-620-1222
  207.    EMail: crocker@cybercash.com
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Huitema, Postel & Crocker                                       [Page 4]
  227.  
  228.